Following you can find the validation changes against the target branch for the API.

You can validate this API yourself by using the make validate target.

Let me check the consequences of this change for the .NET client please, before you merge it.

FieldValue does not look like the best candidate here at a first glance. Would DateTime work? If I remember correctly this type alles string and timestamp representation. However, not sure why the range was a double before. AFAIK we do have double timestamp types as well, but not yet a combined version like DateTime.

We should probably introduce a new type of DateTime does not fit, to allow statically typed languages to use their native DateTime primitives like we do in all other cases that deal with date/time values.

Ok, so I checked this in detail and I think the test is simply not valid.

"aggs": {
  "date_range": {
    "range": {

This part makes no sense. date_range does not support a range field. It supports ranges which is correctly typed as ranges?: DateRangeExpression[] and therefore supports both representations (double and string).

The AggregationRange type you changed in this PR is used by GeoDistanceAggregation and the regular RangeAggregation but does not affect DateRangeAggregation.

WDYT @l-trotta @Anaethelion ?

@flobernd this is not a date_range aggregation... it's a range aggregation, named "date_range" ^^" still, I also think this test is wrong, I can find no evidence server side that from and to can be strings in the context of range aggregation

Ah right, the first key is the name of the aggregation. Confusing 😵‍💫

had to stare at it for a good 2 minutes

@pquentin @l-trotta

I can find no evidence server side that from and to can be strings in the context of range aggregation

Should we remove the faulty test instead?

This was fixed intentionally in elastic/elasticsearch#82732

I can skip the test, but Elasticsearch does accept this query:

{
  "api": "search",
  "file": "/test/free/aggregations/range.yml",
  "name": "Range aggregation on date field",
  "origin": "yaml",
  "request": {
    "args": {
      "body": {
        "aggs": {
          "date_range": {
            "range": {
              "field": "date",
              "ranges": [
                {
                  "from": "2021-05-01T00:00:00Z",
                  "to": "2021-05-05T00:00:00Z"
                }
              ]
            }
          }
        },
        "size": 0
      },
      "index": "date_range_test",
      "typed_keys": true
    }
  },
  "response": {
    "headers": {
      "content-type": "application/json",
      "transfer-encoding": "chunked",
      "x-elastic-product": "Elasticsearch"
    },
    "payload": {
      "_shards": {
        "failed": 0,
        "skipped": 0,
        "successful": 1,
        "total": 1
      },
      "aggregations": {
        "range#date_range": {
          "buckets": [
            {
              "doc_count": 4,
              "from": 1619827200000,
              "from_as_string": "2021-05-01T00:00:00.000Z",
              "key": "2021-05-01T00:00:00.000Z-2021-05-05T00:00:00.000Z",
              "to": 1620172800000,
              "to_as_string": "2021-05-05T00:00:00.000Z"
            }
          ]
        }
      },
      "hits": {
        "hits": [
        ],
        "max_score": null,
        "total": {
          "relation": "eq",
          "value": 5
        }
      },
      "timed_out": false,
      "took": 1
    },
    "statusCode": 200
  }
}

Let's discuss this in the next specification meeting @pquentin 🙂

I think to make this perfect, we have so use untyped variant like for RangeQuery.